一份審查結果，最後仍然錄取相同的三份資料。另一張稽核表卻多了兩份被淘汰的資料，還寫明淘汰原因。這時候，我能說審查「完全沒有改變」嗎？如果只看錄取名單，可以；如果連審查過程知道的事情也算進去，答案就不同了。

這是幫助理解的比喻。2026 年 9 月 1 日凌晨，ARCI 一輪已封存的驗收紀錄遇到了類似問題：R2J，也就是把受治理的檢索結果交給使用端的階段，128 項 focused tests（只檢查這個階段的局部測試）全部通過；但繼承自先前階段的回歸測試，仍有 1 項失敗。因此，那輪驗收沒有完成 R2J 封存，Layer 2 也尚未完成。[1][2]

先交代最新進度：寫作期間，後續契約修復已有局部測試通過，但整體封存又被工作範圍的保全關卡擋下。以下保留原本失敗的原因，並在後段交代這次變化，不把兩輪結果混成同一次驗收。[6]

上一篇問「誰有資格宣布訊息已送達」，原本預告接著談等不到回覆。今天我先轉向這份新的驗收紀錄，因為它讓同一個問題變得更具體：局部成功之後，誰有資格宣布整體完成？本文整理封存證據，不重跑資料庫整合測試，也不把後續修復候選當成通過驗收。[2]

從找到文字，到決定它能不能使用

ARCI（Autonomous Resilient Communication Intelligence）逐步建立的知識流程，已不只是在文字之間找相似。embedding 是把文字轉成可比較的數值向量；資料進來後，還要依固定規則整理、切成區塊，再建立有數量與工作上限的索引。相同輸入重做時，不應任意切出不同區塊，也不應因重複索引而多出一份資料。[3]

接下來的問題是：資料從哪裡來、屬於哪個版本、現在還能不能用？重新索引、撤回與失效，都需要明確規則；來源履歷與有效期限，也要進入檢索資格的檢查。遇到 UNKNOWN，也就是資格尚無法確認時，採取 fail-closed：不能因為缺少證據就先放行。R2D 到 R2I 已分階段建立並封存這些前置能力，但這不等於完成整個第二層平台。[3]

R2J 再把結果整理成不可任意改寫的檢索快照，讓使用端選用證據，並留下 decision trace，也就是這次提供、選用與拒絕哪些證據的決策紀錄。它記錄工程上的選擇，不能證明人的判斷正確，也不是模型內部思考的讀取器。[4]

128 項之外，還有一個舊承諾

局部測試確認新階段的限制能工作，包括拒絕不合資格的證據、保留原因，以及不讓使用端偷偷選走已拒絕的資料。回歸測試則回頭檢查：加入這些能力後，原來答應過的行為還成立嗎？這是兩種不同的證明。[1][4]

失敗發生在 partial staging：新版資料只寫入部分暫存內容，尚未完成正式啟用。測試刻意製造一次寫入確認遺失，檢查舊版正式資料是否繼續有效，新版半成品是否仍被隔離。整個既有資格檢查範圍有 68 項通過、1 項失敗，沒有跳過項目；不能把它縮寫成整體通過。[2]

逐欄比較後，三筆正式採用結果完全相同，連順序、分數、來源履歷、來源版本與新鮮度都沒有變。使用端拿到的證據與 context_id（用來辨識檢索快照的識別值）也相同。額外的邊界檢查還證明，指定一筆暫存證據給使用端，仍然會被拒絕。[2]

問題出在舊測試要求「完整結果相同」，而新契約讓完整結果多知道了一件事：有兩筆資料不能使用。

內容指紋保護的是哪一種相同？

fingerprint 是我把一次檢索結果中被視為重要的欄位，以固定規則整理後產生的內容指紋。只要指紋不同，就代表系統認為兩次結果在某個受保護的意義上不同。它不能保證內容真實，更不是安全或正確性的萬能證明。

這次失敗的指紋，是舊測試對完整檢索結果計算的比較值；不是每筆資料都自帶一個足以證明正確的印章。選哪些欄位、保留什麼順序，實際上就是在定義系統承諾的「同一個結果」。[2]

新增的 rejection audit，中文可稱為拒絕稽核，是結果契約的一部分。原始紀錄顯示，暫存前拒絕清單為空，暫存後新增兩筆；兩筆各自都是 INVALID（不具有效資格），原因各自都是 SUPERSEDED（不符合目前有效版本的取代關係）。這不是一筆叫 INVALID、另一筆叫 SUPERSEDED，也不代表新版半成品曾經正式啟用。[2][4]

觀察到的候選數與拒絕數也隨之增加。逐欄差異全部落在拒絕稽核中，完整結果的指紋因此改變。只看採用的三筆證據，結果相同；把這次查詢範圍內遭拒絕的資料也算進來，治理紀錄就不同了。[2]

圖一：受控測試的概念重畫，A 至 E 是教學代號。拒絕稽核是有範圍與數量上限的當下快照，不代表永久累積的歷史日誌。[2][4]

把稽核拿掉，會失去什麼？

如果我直接把拒絕稽核排除在舊比較之外，指紋就可能重新相同。但若沒有先正式定義比較契約，再獨立驗證被分出去的資料，就只是讓測試忽略原本應該保護的事實。

空結果可能是查詢範圍內沒有資料，也可能是資料已失效、資格 UNKNOWN，或超過有效期限。拒絕稽核讓這些情況不再看起來完全相同：它回答拒絕了什麼，以及為什麼不能使用。刪除紀錄或稱它為純除錯資訊，即使換來測試通過，也會讓系統失去這部分解釋能力。[4]

因此待釐清的不是要不要保留原因，而是正式指紋要代表採用結果、完整治理紀錄，還是分成不同指紋，各自承擔明確責任。分開後也不能只比三個編號；來源版本、新鮮度、順序與快照內容仍須保護，拒絕紀錄的身分、原因、數量與變化也要逐項驗證。[2]

在當時尚未正式定義並驗證這些契約的狀態下，我不能任選最容易讓測試通過的答案，更不能讓暫存資料取得使用資格。

停在這裡，是驗收的一部分

通過新功能的測試，只證明新功能在那些情境下會工作；要宣告完成，還必須證明它沒有改變原本承諾過的世界。

一項必要回歸失敗，就足以阻止封存。這份失敗驗收紀錄沒有建立新的技術提交、沒有推送，也沒有啟動 Layer 3；本篇文件工作同樣不做這些事。停止條件讓尚未釐清的契約留在驗收邊界內，不被當成其他專案可以直接依賴的能力。[2]

這也不是正式環境事故。證據來自隔離資料庫中的合成測試情境，沒有證明 ARCI 在真實災害、醫療或公共安全現場有效。它證明的範圍很窄：這組採用資料未變，拒絕原因被留下，而原本的完整結果不變斷言因此失敗。[2]

寫作期間的新紀錄把比較責任分開：保護完整採用內容，同時檢查拒絕稽核的精確變化，原本的完整指紋仍用於同狀態重播。修復後的資格測試是 121 項通過，R2J 仍是 128 項通過；這已不是原來的 68 項通過、1 項失敗。不過，驗收期間另有文章文件新增，使凍結的工作範圍不再相同，流程依規則停止；後續完整回歸等必要關卡未跑完，沒有新的技術提交。最新阻塞已轉到驗收邊界，不能再稱為同一個指紋 assertion 失敗，也不能宣布平台完成。[6]

未來接進來的專案，應該知道自己接受了什麼

我希望 ARCI 成為可治理的韌性智慧平台。RAG 是把檢索資料帶入生成回答的做法；向量搜尋只是其中一個工具。長期方向是觀察、重建狀態、檢索、評估、提出方案、治理、在界線內執行、驗證，再從結果學習。這是目標循環，不是目前每個環節都已完成，更不是自行改善正式環境的授權。[5]

其他專案接入時，應透過 versioned contracts（有版本的契約）辨識規則，以 compatibility manifest（相容性清單）說明可搭配的版本，再用 contract tests（契約測試）檢查承諾。capability negotiation 是先確認雙方實際具備的能力；controlled promotion 則是通過條件後，才受控地採用新版本。[5]

ARCI 的升級可以形成其他專案的升級候選，不能靜默強迫所有專案一起更新。這些接入機制仍是後續目標；第二層平台尚未完成，本文也沒有替它完成驗收。[5]

真正需要保護的，不只是系統有沒有選到相同的三筆證據，也包括它是否誠實記得另外兩筆證據為什麼不能使用。

參考資料

1. ARCI R2J 局部測試封存輸出：128 項通過，範圍為知識消費階段，不能外推為整體封存。
2. ARCI Layer 2 延續驗收紀錄：原始回歸輸出、暫存前後完整資料、使用端邊界檢查及逐欄診斷；保留未通過判定。
3. ARCI R2D 至 R2I 階段契約與封存紀錄：文字檢索、固定規則的資料處理、索引、生命週期與資格治理，各有驗證範圍。
4. ARCI R2J 知識消費契約與拒絕稽核測試：快照、選用邊界、拒絕原因、數量上限及完整決策紀錄。
5. 本系列的平台目標與升級邊界；對照 Layer 2 契約／相容性紀錄中的未實作項目，不作完成證據。
6. ARCI 後續契約修復與驗收封存紀錄：修復後的資格／R2J 局部輸出，以及工作範圍保全失敗；整體仍未封存。